4-2. 컨테이너를 다루는 도구, 도커(Docker) - 파트 2

4.7. 컨테이너와 프로세스: 프로세스별로 컨테이너 나누기

4.7.1. 하나의 컨테이너에 하나의 프로세스가 기준

컨테이너는 본질적으로 프로세스와 동일함. 따라서 여러 응용 프로그램을 같은 컨테이너에 넣을지는 "이들을 일반적으로 같은 프로세스로 실행하는가"를 기준으로 판단할 수 있음.

예를 들어 웹 시스템을 웹 서버 / AP 서버 / DB 서버의 3계층으로 구성한다고 하면, 한 컨테이너 안에서 세 프로세스를 모두 실행할 수도 있지만 일반적으로 세 서버는 별도 프로세스로 실행함. 따라서 프로세스마다 3개의 컨테이너로 나누는 것이 바람직함.

3계층 웹 시스템의 컨테이너 분리:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[한 컨테이너에 몰아넣기]           [프로세스별로 분리 — 권장]
┌────────────────────┐          ┌────────┐ ┌────────┐ ┌────────┐
│   웹 + AP + DB      │          │ 웹 서버 │ │ AP 서버 │ │ DB 서버 │
│   (3개 프로세스)     │          │ 컨테이너 │ │ 컨테이너 │ │ 컨테이너 │
└────────────────────┘          └────────┘ └────────┘ └────────┘
 ✗ 병목 시 개별 확장 불가           ✓ 병목 컨테이너만 여러 대로 확장
 ✗ 공유 리소스 경합 위험            ✓ 프로세스 격리로 경합 방지

4.7.2. 프로세스별로 컨테이너를 나눌 때 장점

용어 정리

  • 경합 상태 (Race Condition): 여러 프로세스·스레드가 공유 리소스에 동시에 접근할 때 실행 순서에 따라 결과가 달라지는 상태. 재현이 어려운 버그의 원인

4.7.3. 프로세스별로 컨테이너를 나눌 때 단점

4.7.4. 볼륨이란

컨테이너를 삭제하면 컨테이너의 데이터도 사라짐. 데이터를 남겨 두고 싶으면 도커 볼륨(Volume)을 사용해야 함.

바인드 마운트(Bind Mount)는 볼륨과 비슷하지만 호스트 운영 체제의 파일 시스템을 컨테이너에 마운트한다는 점이 다름. 파일 시스템 공유는 가능하나 제약이 많으므로, 컨테이너 간 공유에는 볼륨이 더 나음. 바인드 마운트는 주로 호스트와 컨테이너 간 파일 시스템 공유에 사용함.

용어 정리

  • 볼륨 (Volume): 컨테이너가 읽고 쓰는 데이터를 지속화하기 위해 도커가 관리하는, 이름이 붙은 디렉터리
  • 지속화 (Persistence): 프로그램이 종료되어도 데이터가 손실되지 않도록 저장하는 것
  • 바인드 마운트 (Bind Mount): 호스트 OS의 특정 경로를 컨테이너에 직접 마운트하는 방식

볼륨 vs 바인드 마운트:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[도커 볼륨]                          [바인드 마운트]
┌───────────┐  ┌───────────┐        ┌───────────┐
│ 컨테이너 A │  │ 컨테이너 B │        │  컨테이너  │
└─────┬─────┘  └─────┬─────┘        └─────┬─────┘
      └──────┬───────┘                    │
             ▼                            ▼
   ┌────────────────────┐      ┌────────────────────┐
   │ 도커가 관리하는      │      │ 호스트 OS의 임의     │
   │ 전용 디렉터리(이름)  │      │ 경로(파일/디렉터리)  │
   └────────────────────┘      └────────────────────┘
   → 컨테이너 간 공유에 적합       → 호스트 ↔ 컨테이너 공유에 사용
   → 제약이 적음                  → 제약이 많음
구분 도커 볼륨 (Volume) 바인드 마운트 (Bind Mount)
저장 위치 도커가 관리하는 전용 디렉터리 호스트 OS의 임의 경로
관리 방식 이름으로 관리 (도커가 관리) 호스트 경로를 직접 지정
주 용도 컨테이너 간 파일 시스템 공유·데이터 지속화 호스트 ↔ 컨테이너 간 파일 공유
제약 적음 (권장) 많음

4.8. 네임스페이스

4.8.1. 네임스페이스란

4.8.2. 네임스페이스와 컨테이너

도커는 네임스페이스를 이용해 다른 컨테이너와 격리함.

네임스페이스에 의한 컨테이너 격리:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

              [도커 데몬]
                  │ 컨테이너를 실행할 때마다
                  ▼
   ┌───────────────────────────────┐   ┌────────────────┐
   │  네임스페이스 A (컨테이너 A)    │   │ 네임스페이스 B  │
   │  ┌────────┐   ┌────────┐      │   │ (컨테이너 B)    │
   │  │ 최초    │→ │ 자식    │ ...   │   │  ┌────────┐    │
   │  │ 프로세스│   │ 프로세스│      │   │  │  ...    │    │
   │  └────────┘   └────────┘      │   │  └────────┘    │
   │  → 내부에서 외부가 보이지 않음  │   └────────────────┘
   └───────────────────────────────┘
   "보이지 않는다면 없는 것과 같다" — 필터 역할

4.8.3. 네임스페이스에 의해 격리된 리소스

네임스페이스는 다양한 리소스를 격리할 수 있음. 예를 들어 PID 네임스페이스는 프로세스 ID를 격리해 다른 컨테이너에서 동일한 프로세스 ID를 사용할 수 있게 하고, 네트워크 네임스페이스는 네트워크 인터페이스와 포트 번호를 격리해 컨테이너마다 다른 IP 주소를 할당할 수 있게 함.

네임스페이스 격리하는 리소스
PID 네임스페이스 프로세스 ID
네트워크 네임스페이스 네트워크 인터페이스, 포트 번호
IPC 네임스페이스 프로세스 간 통신
마운트 네임스페이스 파일 시스템
UTS 네임스페이스 호스트명

4.8.4. 컨트롤 그룹이란

용어 정리

  • 네임스페이스 (Namespace): 리소스를 "보이지 않게" 하여 프로세스를 격리하는 리눅스 커널 기능
  • 컨트롤 그룹 (cgroups): 프로세스 집합이 사용하는 하드웨어 리소스(CPU·메모리·디스크 I/O 등) 사용량을 제한하는 리눅스 커널 기능

4.8.5. 컨트롤 그룹의 계층 구조

격리(네임스페이스) vs 제한(컨트롤 그룹):
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[네임스페이스] — "보이지 않게"        [컨트롤 그룹(cgroups)] — "얼마나 쓸지"
├─ PID (프로세스 ID)                 ├─ CPU 코어 수
├─ 네트워크 (인터페이스·포트)         ├─ 메모리 용량
├─ IPC (프로세스 간 통신)            └─ 디스크 I/O
├─ 마운트 (파일 시스템)
└─ UTS (호스트명)                    계층 구조 (cgroupfs)
                                    └─ 상위 제한을 하위가 상속 · 초과 불가

4.9. 차분 관리

4.9.1. 차분 관리란

4.9.2. 이미지 레이어의 특징

4.9.3. 컨테이너 레이어의 특징

이미지 레이어와 컨테이너 레이어:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

 ┌──────────────────────────────┐
 │  컨테이너 레이어 (쓰기 가능)   │ ← 컨테이너와 함께 생성·삭제
 ├──────────────────────────────┤
 │  이미지 레이어 3 (읽기 전용)   │ ┐
 ├──────────────────────────────┤ │ 각 레이어는 직전 레이어와의
 │  이미지 레이어 2 (읽기 전용)   │ │ '차분'만 기록
 ├──────────────────────────────┤ │
 │  베이스 이미지 레이어 (읽기전용)│ ┘
 └──────────────────────────────┘

[파일 쓰기 — 카피 온 라이트(Copy-on-Write)]
 이미지 레이어의 파일 수정 요청
   → 파일을 컨테이너 레이어로 복사한 뒤, 복사본을 변경

[파일 읽기]
 모든 레이어에서 대상 파일을 검색 → 가장 새로운 버전을 읽음
구분 이미지 레이어 (Image Layer) 컨테이너 레이어 (Container Layer)
쓰기 가능 여부 읽기 전용 (변경 불가) 쓰기 가능
생성 시점 이미지 빌드 시 컨테이너 실행 시
라이프 사이클 이미지에 귀속, 재사용됨 컨테이너와 동일 (삭제 시 함께 삭제)
기록 내용 직전 레이어와의 차분 프로세스가 추가·변경한 파일

4.9.4. 차분 관리의 장단점

장점

단점

4.10. 스웜 모드

4.10.1. 스웜 모드란

4.10.2. 매니저와 워커

도커는 스웜 내 노드에 매니저 / 워커 / 매니저 겸 워커 세 역할 중 하나를 부여함.

스웜 모드의 구조:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

 사용자 ──서비스 정의──▶ ┌───────────────────┐
 (이미지·복제 수 등)      │  매니저 (엔드포인트)  │ ◀─ 여러 매니저로 이중화
                        └─────────┬─────────┘
                     컨테이너 실행 계획·지시
              ┌────────────────┼────────────────┐
              ▼                ▼                ▼
         ┌────────┐       ┌────────┐       ┌────────┐
         │ 워커 1  │       │ 워커 2  │       │ 워커 3  │
         │ [태스크]│       │ [태스크]│       │ [태스크]│ ← 태스크 = 워커의 컨테이너
         └────────┘       └────────┘       └────────┘
         스웜(Swarm) = 도커 호스트(노드)들의 클러스터

4.10.3. 서비스와 태스크

4.10.4. 클러스터를 관리하는 도구

4.11. 도커의 주요 명령어

4.11.1. 도커 명령어를 사용할 수 있는 환경

4.11.2. 도커 명령어의 기본

도커 명령어의 구조:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  docker   container   run   -i -t   ubuntu:26.04    /bin/bash
    │          │        │      │          │              │
  기본       관리     명령어   옵션      이미지         컨테이너 내
  명령      명령어                                      실행 명령

  옵션: -i  (하이픈 1개 + 영문 1글자)   /   --help  (하이픈 2개 + 영어 단어)

4.11.3. 컨테이너의 시작 / 분리 / 표시 / 정지 / 삭제

작업 명령어 / 조작 비고
시작 docker container run -i 키보드 입력 활성화, -t 셸 프롬프트 표시 활성화
분리 (detach) Ctrl + P → Ctrl + Q 시작한 컨테이너에서 빠져나오는 조작
상태 확인 docker container ls 컨테이너 ID, 이미지 등 확인
정지 docker container stop 실행 중인 컨테이너 정상 정지 (SIGTERM → 유예 시간 후 SIGKILL)
강제 정지 docker container kill 즉시 SIGKILL로 강제 종료
정지 포함 전체 표시 docker container ls -a -a = 정지한 모든 컨테이너 표시
삭제 docker container rm 남아 있는 컨테이너 레이어 삭제 
~$ docker container run -i -t ubuntu:26.04 /bin/bash
2026-10 갱신

  • 원서 예시의 centos:latest는 CentOS Linux 지원 종료(CentOS 7 EOL: 2024-06)로 더 이상 권장되지 않음 → ubuntu:26.04(현행 LTS)로 교체. RHEL 계열이 필요하면 rockylinux:9 사용
  • 원서는 정지 명령으로 docker container kill을 소개하지만, 일반적인 정지는 docker container stop(SIGTERM 전송 → 유예 시간(기본 10초) 후 SIGKILL)이 정상 종료 방식. kill은 즉시 SIGKILL을 보내는 강제 종료

참고

컨테이너를 정지한 후에도 컨테이너 레이어는 남아 있음. docker container ls -a로 확인하고 docker container rm으로 삭제함.

4.11.4. 컨테이너 이미지의 생성 / 표시 / 삭제

작업 명령어 비고
생성 docker container commit 실행 중인 컨테이너로부터 이미지 생성
표시 docker image ls 리포지터리, 태그, 이미지 ID 등 확인
삭제 docker image rm

4.11.5. 도커 파일로 컨테이너 이미지 생성

명령어 설명
FROM 기본(베이스) 컨테이너 이미지를 지정
WORKDIR 컨테이너의 작업 폴더를 지정
COPY 파일 및 디렉터리를 컨테이너에 복사
RUN 컨테이너에서 명령을 실행
EXPOSE 컨테이너가 외부에 공개하는 포트를 선언
CMD 기본 시작 명령을 지정

4.11.6. 도커 명령어를 사용하는 곳

4.12. 도커 허브: 컨테이너 이미지를 공유할 수 있는 서비스

4.12.1. 도커 허브란

4.12.2. 컨테이너 레지스트리란

컨테이너 레지스트리의 계층과 푸시 / 풀:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

 ┌────────────────────────────────────────────┐
 │        컨테이너 레지스트리 (도커 허브 등)      │
 │  ┌──────────────────┐  ┌─────────────────┐  │
 │  │ 리포지터리: nginx  │  │ 리포지터리: ...  │  │
 │  │  ├─ 이미지 :latest │  │                 │  │
 │  │  ├─ 이미지 :1.25   │  │ (같은 이미지의   │  │
 │  │  └─ 이미지 :stable │  │  버전들을 태그로) │  │
 │  └──────────────────┘  └─────────────────┘  │
 └──────────────────▲──────────────────┬───────┘
          Push(업로드) │              │ Pull(다운로드)
                       │              ▼
                 ┌──────────────────────┐
                 │   도커 호스트 / 개발자  │
                 └──────────────────────┘

4.12.3. 리포지터리와 태그

4.12.4. 도커 허브 이외의 컨테이너 레지스트리 서비스

클라우드 서비스명
AWS Amazon ECR (Elastic Container Registry)
GCP Artifact Registry (구 Container Registry)
Azure Azure Container Registry (ACR)
2026-10 갱신

  • GCP의 Container Registry는 2025년에 종료되어 Artifact Registry로 대체됨

핵심 요약

4-2장. 도커 심화: 격리 기술 · 레이어 · 클러스터 · 명령어 요약:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[컨테이너와 프로세스]
├─ 원칙: 1 컨테이너 = 1 프로세스 ("같은 프로세스로 볼 수 있는가"로 판단)
├─ 장점: 병목만 개별 확장 · 오버헤드 거의 없음 · 경합 상태 방지
└─ 단점: 관리 복잡(→ 오케스트레이션) · 리소스 공유 전제 SW는 부적합

[데이터 지속화]
├─ 볼륨: 도커가 관리하는 이름 붙은 디렉터리 · 여러 컨테이너에 동시 마운트
└─ 바인드 마운트: 호스트 경로를 마운트 · 주로 호스트 ↔ 컨테이너 공유

[격리 기술]
├─ 네임스페이스: 리소스를 '보이지 않게' 격리 (PID · 네트워크 · IPC · 마운트 · UTS)
└─ 컨트롤 그룹(cgroups): 하드웨어 사용량 '제한' (CPU · 메모리 · 디스크 I/O) · 계층 상속

[차분 관리]
├─ 이미지 레이어: 읽기 전용 · 직전 레이어와의 차분만 기록
├─ 컨테이너 레이어: 쓰기 가능 · 컨테이너와 라이프 사이클 동일
├─ 카피 온 라이트: 수정 시 파일을 컨테이너 레이어로 복사한 뒤 변경
└─ 장점(빠른 배포 · 용량 절감) ↔ 단점(잦은 쓰기 시 성능 저하 → 볼륨으로 완화)

[스웜 모드]
├─ 도커 엔진 내장 클러스터 관리 (스웜 = 도커 호스트/노드들의 클러스터)
├─ 역할: 매니저(관리 · 엔드포인트) / 워커(컨테이너 실행)
├─ 서비스(원하는 상태 정의) → 태스크(워커의 컨테이너, 최소 단위)
└─ 현재는 쿠버네티스를 공식 지원하며 방향 전환

[주요 명령어]
├─ 컨테이너: run(-i -t) / ls(-a) / stop(강제: kill) / rm , 분리 = Ctrl+P → Ctrl+Q
├─ 이미지: container commit / image ls / image rm
├─ Dockerfile: FROM · WORKDIR · COPY · RUN · EXPOSE · CMD
└─ 예: run -v(마운트) -d(백그라운드) -p(포트 할당)

[도커 허브 / 레지스트리]
├─ 레지스트리 > 리포지터리 > 이미지 (태그: latest · stable …)
├─ 푸시(업로드) / 풀(다운로드) — Docker Registry HTTP API
└─ 그 외: Amazon ECR · GCP Artifact Registry · Azure ACR

참고 자료

관련 자료:

네비게이션

이전 강 목록 다음 강
◀ 4-1. 컨테이너를 다루는 도구, 도커(Docker) - 파트 1 목록으로 5-1. 컨테이너 오케스트레이션 도구, 쿠버네티스 - 파트 1 ▶